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is  shown  to  provide  a greater  degree  of  expandability  and  maintainability 
than  is  found  with  operating  systems  developed  with  less  structured  proiiram- 
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DD  1473  COITION  OF  I NOV  0%  IS  OBSOLCTC 


S/N  OtO;  tF  014  AbO 


nv  •'a't 


tCCUMITV  CL  AISI 


FICATION  or  THIS  RAOt  (iniAn^Als  «n 

r 

. ' r—  r w ' 


w 


CC  ASSiFiC  ATION  OF  THIS  PAGCriFhtn  D«r«  Fnf«r«tf) 
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environment  requires  the  ability  of  user-computer  communication 
at  a high  level.  This  operating  system  provides  an  environment 
which  facilitates  the  development  of  special  purpose  languages 
at  a very  high  level  by  means  of  the  threaded  code. 

The  principles  of  the  design  of  the  system  are  discussed 
and  contrasted  with  other  reported  approaches  to  laboratory 
computing.  Exanples  which  demonstrate  the  multilevel  nature  of 
the  design  and  the  advantages  of  this  approach  are  described. 
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\ ABSTRACT 

An  operating  system  for  a laboratory  computer  network  has  been  im- 
plemented utilizing  the  principles  of  hierarchically  structured  soft- 
waj'e  and  hardware.  The  system  was  developed  using  a threaded  code  tech- 
nique which  is  shown  to  provide  a greater  degree  of  ex|)andability  and 
maintainability  than  is  found  with  operating  systems  developed  with  less 
structured  programming  techniques.  The  continuous  evolution  of  computing 
needs  in  a research  environment  requires  the  availability  of  user-computer 
communication  at  a high  level.  This  operating  system  provides  an  environ- 
ment which  facilitates  the  development  of  special  purpose  languages  at  a 
very  high  level  by  means  of  the  threaded  code. 

The  principles  of  the  design  of  the  system  are  discussed  and  con- 
trasted with  other  reported  approaches  to  laboratory  computing,  examples 
which  demonstrate  the  multilevel  nature  of  the  design  and  the  advantages 
of  this  approach  a»'e  described. 
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INTRODUCTION 

In  a typical  university  ctiemistry  research  envi rominMit,  computer 
system  support  is  required  for  a variety  of  research  projects  in  atvas 
such  as  chromatography,  electrochemistry,  and  spectroscopy,  among  others. 
The  type  of  computer  support  required  varies  greatly  from  experiment  to 
experiment,  but  usually  includes  direct  instrument  control,  data  acquisi- 
tion and  storage,  and  computation  of  results.  Instrument  control  may 
involve  the  use  of  fixed  programs  for  a given  class  of  experinuMits  or  it 
may  require  sophisticated  interaction  with  the  user.  Data  acquisition 
requirements  can  vary  from  low  speed,  high  volume  data  to  very  high  speed, 
relatively  low  volume  data.  Soine  experiments  may  require  small  amounts 
of  real-time  computations,  while  others,  such  as  simulations,  may  run  for 
hours  or  days.  At  any  given  time,  approximately  ten  people  may  be  oiiployed 
in  up  to  ton  diffet'ent  research  projects  requiring  some  kind  of  comj)uter 
support. 

The  fundamental  problem  in  laboratory  computing  is  making  computer 
services  available  to  the  experimenter  when  and  who»'e  they  are  needed  at 
a reasonable  cost  in  equipment  and  user  time.  This  envi  roniient  is  an 
especially  difficult  one  because  of  its  very  wide  range  of  comjnjtati on, 
data  acquisition  rate,  and  data  volume  problems.  The  constant  evolution 
of  the  software  required  by  the  ever  changing  nature  of  •'esearch  adds  an 
extra  complication. 
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Most  of  the  specific  problems  of  laboratory  coiniuting  can  be  des- 
cribed in  terms  of  communication  or  information  flow  requirements.  Data 
acquisition  obviously  involves  a flow  of  information  from  instrun)ent  to 
computer.  Similarly,  instrument  control,  data  reduction,  and  presentation 
of  results  can  be  thought  of  as  information  flow  problems.  The  need  to 
change  software  through  programming  is  also  an  information  floiv  problem 
because  the  user  must  communicate  his  ideas  to  the  computer. 

The  purposes  of  a laboratory  conputer  operating  system  are  to  pro- 
vide for  orderly  information  flow  aiflong  the  hardware  and  software  com- 
ponents involved  in  an  experiment  and  to  communicate  with  the  user  of 
the  system.  Specific  services  are  provided  to  aid  in  moving  data  and 
results  from  experiment  to  user  and  commands  from  user  to  experiment. 

Other  services  are  provided  to  aid  in  application  software  development. 

The  effect  of  these  sets  of  system  services  is  to  create  an  environitcnt 
in  which  experiments  may  be  iiwre  conveniently  performed. 

The  environment  provided  by  the  system  software  is  much  itore  struc- 
tured than  that  provided  by  the  bare  minicomputer  hardware.  This  struc- 
ture along  witli  the  specific  services  provided  by  the  system  simplifier 
the  writing  of  application  programs  by  reducing  the  number  of  decisions 
a prograniner  must  nake  and  the  amount  of  detail  included  in  each  program. 

However,  a more  specifically  structured  environment  is  necessarily  less 
general  than  the  hardware  environment.  An  operating  system  improves 
applicability  to  those  kinds  of  information  flow  problems  most  likely  to 
be  encountered  by  reducing  generality.  A system  designed  to  a wider 
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•Muye  of  applications  requires  (ji-eatiM'  generality  and,  therefore,  is 
more  difficult  to  implement  and  less  satisfactory  for  any  one  applica- 
tion. Thus,  there  ar't*  some  very  iiood  turn-key  systems  designed  for 
specific  applications,  but  few  general  purpose  research  laboratory  com- 
puter systems.  The  ideal  laboratory  coiivuter  system  should  provide  a 
flexible  environiix'iit  as  an  overall  structui*e  plus  somt?  iix'ans  of  creating 
special  jnirpose  envi roniik'nts  for  specific  classes  of  problems. 

In  a well-structured  envi ronim'nt , there  is  at  least  somt'  hope  that 
independently  designed  programs  can  communicate  with  each  other  and  that 
programnx'rs  can  understand  each  others  work.  The  structure  should  im- 
pose an  automatic  discipline  on  the  system  users,  guiding  tl\em  into 
coiix'atiblc  program  and  data  constnictions.  This  is  especially  important 
in  a university  settit\g  wheiv  the  users  iiMSt  often  are  students  who 
have  not  yet  developed  much  self-discipline  in  progranming  and  will  not 
he  around  long  enough  to  maintain  their  own  work.  However,  because  of 
the  tvgui  jvimnits  of  flexibility  in  reseatvh  projects,  this  discipline 
must  be  imposed  \<ithout  excessive  I'estri ctions  on  generality.  It  is 
better  to  provide  standard  nx'ans  for  solving  problems  rather  tlian  re- 
stricting the  kinds  of  problems  wliich  can  be  solved. 

This  paper  describes  an  innovative  approach  to  an  operating  system 
which  is  capat>le  of  |>roviding  the  low  level  generality  needed  to  coiiiiiuni- 
cate  with  a variety  of  specific  instruments  as  well  as  providing  the 
high  level  of  comiiRinication  requi»vd  by  a variety  of  continuously  evolving 
experimi'nts. 


Hierarchically  Structured  Hardware 


The  only  economical  way  to  provide  the  required  variety  of  computer 
services  in  this  research  laboratory  environment  is  through  the  use  of  a 
hierarchy  of  computers.  For  efficiency,  expensive  peripheral  equipment 
and  sophisticated  software  are  shared,  as  much  as  possible,  in  one  cen- 
tral system  which  is  oriented  toward  the  support  of  software  development 
and  data  reduction  computation.  Such  a medium  to  large  scale  central 
system  cannot,  however,  be  made  sufficiently  flexible  and  general  to  also 
support  simultaneous  data  acquisition  and  experiment  control  under  a 
wide  range  of  conditions.  Small,  dedicated  systems  can  better  handle 
the  data  acquisition  and  experiment  control  problems,  but,  without  a 
large  investment  in  peripheral  equipment  and  system  software,  they  are 
not  able  to  supply  adequate  softv/are  development  and  computation  ser- 
vices. Dividing  computer  support  services  into  two  classes,  operating 
in  two  different  environments,  results  in  better  service  in  both  environ- 
ments. 

Our  approach  to  this  problem  has  been  to  develop  a computer  system 
which  provides  for  a division  of  labor  between  one  central  computer  and 
several  (currently  two)  peripheral  computers.  The  hardware  structure  for 
this  system,  which  is  known  as  the  Hierarchical  Interactive  Sharing  Sys- 
tem (HISS)j  is  shown  in  Figure  1,  The  peripheral  computers  can  devote  their 
full  attention  to  the  instruments  attached  to  them  while  the  central  com- 
puter provides  the  data  storage  capacity,  coiiputing  power,  and  extensive 
peripheral  equipment  to  effectively  extract  information  from  the  data. 

Also,  during  the  software  preparation  phase,  the  central  computer's 
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nore  extensive  nieniory  and  peripherals  greatly  improve  the  prograiiKiier ' s 
efficiency. 

If  support  services  are  divided  between  local  instrument  control 
con\puters  and  a central  computer,  then  some  fonii  of  communication  must 
' be  provided  for  the  transfer  of  data,  coninands,  and  programs.  This  com- 

I munication  may  be  through  user  carried  messages,  common  peripherals  ' 

such  as  paper  or  magnetic  tape,  direct  data  lines,  shared  peripherals 
such  as  a single  disc  drive  for  two  computers,  or  even  shared  main  memory. 

,1  I 

;t  The  various  communication  possibilities  have  a wide  range  of  data  trans-  I 

fer  rates,  complexities,  and  costs. 

1 

The  mss  system  uses  multiplexed  direct  parallel  data  lino  coinnuni-  j 

cation  between  the  central  computer  and  each  peripheral  computer.  This 
technique  offers  sufficient  data  transfer  speed  for  our  experiments,  | 

allows  the  central  and  local  computers  to  be  located  in  different  labora-  I 

i 

tories,  and  is  not  too  difficult  or  expettsive  to  Iniild.  The  multiplexor 

electronics  are  illustrated  by  a simplified  schenwtic  in  Figure  2.  Un-  \ 

1 

! , 

, der  central  computer  software  control  any  one  of  up  to  15  neripheral 

! ' i 


coiivutor  stations  may  be  seloctod  by  tlie  multiplexor.  Infornwition  nuiy 
then  be  transtertvd,  in  parallel,  in  either  direction  at  rates  ot  up  to 
JOO.OOO  U)-bit  words  per  second.  Ihe  actual  rate  depends  on  the  lenuth 
of  the  connecting  cable  and  the  spei'd  of  tlie  oenplu'ral  coinniler. 

^^t\iui  renxMits 

Operating  system  softwaiv  is  miuired  to  support  this  hierarchical 
ha»\1ware  oi'ijani  cat  i on  and  the  application  proorams  usiiuj  it.  Tiiis  system 
must  provide  efficient  coimminicat  ions  between  the  central  comt'oter  and 
peripheral  computers  so  that  system  services  can  be  effectively  used  by 
experinx'iits  while  the  flexibility  of  the  peripheral  coiiputers  is  main- 
tained. 

The  following  ooals  were  set  for  the  desipn  of  ttiis  laboratorv  com- 
puter system: 

1.  Provide  leal-tinx'  data  acoui  si  t ion  for  a variet\  of  unrelated 
experi  Wilts. 

Provide  mass  storage  for  data  and  prograiniiiiuj. 

3.  Provide  interactive  control  of  experiiwnts. 

4.  Provide  sooiiisticated  data  massaqiiuj  durinq  experinx'iits. 

5.  Provide  relatively  fast  computational  speed. 

6.  Provide  for  appropriate  maintainability  ot  system  software. 

7.  Provide  for  futuiv  expandability  t^f  system  software. 

8.  Provide  both  the  flexibility  necessary  for  a ivsearch  environ- 
ment and  sufficient  structui'e  to  lessen  author  dependence  of 
user  software. 

Provide  for  efficient  chemist-comtniter  communication  at  a level 
consistent  with  the  problem  and  the  chemists  background. 

A corntniter  system  may  be  put  together  and  operated  in  a qivat  iiMiiy 
different  w^ys.  At  the  time  this  system  was  beinq  planned,  the  only 
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viable  choices  for  the  hardware  were  minicomputers  from  various  manu- 
facturers. More  recently,  smaller  and  less  expensive  microprocessors 
have  been  developed.  These  are  logical  candidates  for  peripheral  com- 
puters in  a laboratory  computer  network.  Experiences  witli  the  HISS 
system  should  be  applicable  to  designs  using  them  as  well  as  to  the 
minicomputers  actually  employed. 

Software  for  microprocessor  based  laboratory  systems  is  still  poor- 
ly developed  because  their  very  low  hardware  cost  discourages  spending 
very  much  on  system  software.  They  have  been  used  principally  in  the 
research  laboratory  as  built  in  controllers  for  instrumentation  rather 
than  as  user  programmable  computers.  As  parts  of  a hierarchical  system, 
however,  they  could  become  an  important  addition  to  general  purpose  labora- 
tory computing  systems. 

Software  for  minicomputer  based  laboratory  systems  is  more  readily 
available  than  it  is  for  microprocessor  systems,  but  it  is  still  not 
satisfactory  for  hierarchically  structured  hardware  or  the  kinds  of  ex- 
periments performed  in  this  laboratory.  The  central  comjniter  operated 
initially  under  a fairly  simple  disc  based  operating  system  and  each 
peripheral  computer  operated  under  an  even  simpler  core  based  operating 
system.  None  of  these  operating  systems  are  very  well  designed  for  a 
laboratory  conputer  environment.  They  are  good  examples  of  older,  larger 
scale  conputer  system  designs  reduced  in  size  and  capabilities  and  put 
into  a small  laboratory  computer.  Communication  between  computers  occurs 
through  coninon  I/O  devices  such  as  paper  tape,  a slow,  bulky,  and  error 
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1 prone  iiiediuin.  Consequently,  very  little  communication  between  coiiputers 

occurred. 

Most  vendors  of  laboratory  conputers  have  sore  kind  of  real-time 
executive  (RTL)  operating  system  designed  to  enhance  instrument  control 
capabilities  of  their  computers.  The  Hewlett-Packard  flTE  system,  which 
is  typical  of  this  class,  is  a much  improved  version  of  their  disc  operat- 
ing system.  The  added  mul tiprogranriing  capabilities  allow  the  conputer 
to  service  instruments  in  a real-time  mode  while  executing  another  pro- 
gram in  whatever  time  is  left  over.  This  system  is  intended  to  be  used 
for  directly  controlling  several  instruments  simultaneously  by  time 
sharing  one  central  processing  unit.  There  may,  however,  bo  considerable 
system  overhead  and  delay  in  responding  to  requests  from  attached  instru- 
ments, especially  if  more  than  one  of  them  can  produce  data  at  a fairly 
high  rate. 

Time  sharing  of  one  processor  for  several  independent  operations 
must  I'esult  in  increased  operating  system  overhead  and  slower  response. 

Of  even  more  iiiportancc,  however,  is  the  resulting  software  complexity. 
When  central  processors  we»'0  very  expensive,  there  was  some  economic 
justification  for  sharing  one  processor  among  several  tasks.  The  ex- 
pense of  writing  and  maintaining  extremely  conplex  software  could  be  re- 
covered by  nuking  one  processor  do  the  job  of  several.  This  j-eason  for 
mul tiprogranining  systems  is  no  longer  very  important  and  the  disadvantages 
of  extremely  complex  softwaj'e  are  becoming  more  apparent.  Such  systems 
are  difficult  to  maintain  even  by  the  original  authors.  Ordinary  users 
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have  little  hope  of  beinq  able  to  make  any  changes  at  all  in  them  to 
acconinodate  new  kinds  of  hardware  or  experiments. 

Conaiiuni eating  with  the  Laboratory  Computer 

I 

Software  development,  either  the  creation  of  new  programs  or  the 
modification  of  old  ones,  requires  some  form  of  communication  between  pro- 
grammer and  computer.  Having  efficient  communication  is  especi.illy  im- 
portant in  a chemical  research  environment  because  of  the  evolvinc)  nature 
of  the  software  and  the  often  limited  programming  experience  of  the 
users. 

In  some  laboratory  comfjuter  systems,  for  example  IIASIC  language 
systems,  the  operating  system  and  the  programming  langua(|e  used  to  com- 
municate with  it  are  practically  indistinguishable.  It)  otliers,  there 
n.oy  be  distinct  divisions  between  system  and  languagt's.  Hut,  since  in 
all  cases  the  programming  languages  available  are  a major  factor  in  de- 
fining the  environment  in  which  users  work,  we  will  consider  tl)em  as 
parts  of  the  operating  system.  The  programming  languages  available  witli 
small  laboratory  computer  systems  are  usually  quite  limited  botl)  in 
number  and  capabilities. 

The  operating  systems  themselves  are  usually  written  in  a low 
level  assembly  language  compounding  system  software  maintenance  pro- 
blems. Assembly  language  may  also  bo  used  for  application  programs  and 
usually  must  be  used  for  those  few  programs  directly  concerned  with  in- 
strument interfacing,  for  niost  programs,  however,  the  excessive  (lenera- 
lity  of  the  language  results  in  unnecessary  program  complexity  because 
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of  the  1ar()o  nuiiil)tM'  of  coding  details  regoired.  To  make  any  chanqes  in  j 

■i 

a program  whenever  computing  needs  change,  a user  must  hecoim'  familiar 
with  all  these  details. 

lli()her  level  languages  help  improve  progranniK'r  to  computer  comnuni- 
cation.  because  they  are  iiwre  specific,  higher  U'vel  languages  reguire 
less  detail  to  express  those  kinds  of  algorithms  for  which  they  are  de- 
signed. The  only  higher  level  languages  coiiiiHinly  used  with  small  lahora-  i 

tory  com|)uters  are  I ORTRAN  and  bASlC,  both  of  which  were  desigiw’d  for  j 

other  purposes  and  do  not  completely  satisfy  the  needs  of  a r('S('a)'(  h lah-  | 

oratory  envi  ronnx'nt . i 

Systems  huilt  around  the  liASlC  language  have  the  advantages  of  being  i 

i 

inti'ractive  and  relatively  easy  to  leai'n  (Wilkins  and  Klopf enstei n , 1')/.?).  j 

j 

These  two  prope>'ties  are  especially  important  it\  a research  lal'oratory  en-  ‘ 

vironment  because  of  the  continually  changing  software  and  the  laik  ot 
programming  experience  of  son*'  users.  As  long  as  experiim'iits  remain  fairly 
slow  and  simple,  bASlC  can  provide  an  excellent  nu'ans  ot  communit  at  in<i  with 
the  laboratory  computer. 

RASIC  has  two  fui\daiix'nta  1 limitations,  howev»'r.  tirsi,  it  is  an 
interpretive  latuiua()e,  and,  therefore,  too  slow  to  keep  up  with  soim' 
high  speed  instruments  oi-  to  perform  extensive  computations,  such  as 
simulations.  Second,  it  is  an  easy  to  learn  and  us('  lamiuage  only  if 
the  programs  are  very  small.  Its  lack  of  modular  structuring  is  a st'rious 
deficiency  in  a research  envi  ronim'nt.  The  programim'r  cannot  write  a 
series  of  iiH)dules  winch  may  be  combined  to  make  programs,  but,  instead, 
must  write  each  program,  no  matter  how  comtilex,  as  a unit. 
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FORTRAN-based  laboratory  coitiputer  systems  avoid  the  more  serious 
limitations  of  BASIC  language  systems  at  some  expense  in  increased  sys- 
tem software  complexity  and  reduced  interactive  capabilities.  Most  iru- 
portantly,  FORTRAN  systems  allow  the  user  to  build  programs  from  modular 
subprograms  written  in  either  FORTRAN  or  assembly  language.  A complex 
program  may  be  broken  into  smaller,  more  managable  subprograms  with  only 
limited  and  well-defined  conmuni cation  between  tl)em.  And,  if  the  sub- 
programs are  made  general  enough,  they  can  Ite  gathered  into  libraries  for 
use  by  other  prograniners  working  on  future  projects. 


Despite  its  advantages  over  BASIC,  FORTRAN  remains  a poorly  struc- 
tured language.  For  problems  limited  to  input,  calculation,  and  output, 
it  is  adequate.  But,  if  many  decisions  are  required  or  complex  data 
structures  are  involved,  then  programs  become  excessively  convoluted  and 
confusing.  Subprogram  structures  are  less  efficient  and  harder  to  use 
than  they  are  in  many  other  languages. 

There  are  quite  a numl,er  of  less  well-known  (to  chemists)  systems 
and  languages  which  could  be  applied  in  the  chemical  laboratory.  A very 
elegant  example  is  the  UNIX  system  which  was  written  for  the  POP-11  at 
Bell  laboratories  (Ritchie  and  Thompson,  1974).  This  system  has  been  very 
successful  because  it  provides  a simple,  yet  powerful,  environment  for 
users  and  their  programs.  Its  strongest  point  seems  to  bo  consistency  in 
I/O  and  file  structures  allowing  programs  to  very  effectively  communicate 
with  each  other  and  with  users. 
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FORTH  (Moore,  1974)  provides  a limited  laboratory  coiiputer  operating 
system  and  a high  level  programming  language  based  on  hierarchical  struc- 
turing and  is  available  for  a number  of  different  computers,  including  the 
HP  2100  series.  At  the  time  this  system  was  designed,  FORTH  was  limited 
to  dedicated  computer- instrument  systems.  It  was,  therefore,  unacceptable 
for  use  in  a central  computer,  although  potentially  useful  in  peripheral 
computers.  Recently,  it  has  been  extended  to  include  multiprogramming 
capabilities  similar  to  an  RTE  operating  system  (Rather  and  Moore,  1976). 
This  extension,  while  useful  in  some  applications,  suffers  the  same  limi- 
tations as  other  RTE  type  systems. 

Communicating  with  a laboratory  conputer  using  FORTH  is  much  easior 
than  with  the  programming  languages  available  on  nwst  systems.  Tl\e  criti- 
cisms of  it  as  a progranming  language  are  more  of  a technical  nature  ratiier 
than  of  the  principles  upon  which  it  is  based.  Because  of  its  poor  syn- 
tax, it  tends  to  be  hard  to  read  and  does  not  encourage  the  use  of  com- 
ments. A lack  of  localization  structuring  makes  in  vulnerable  to  foolisli 
mistakes  by  uninformed  users.  In  some  situations,  it  is  inefficient  and 
slow  duo  to  excessive  overhead  processing. 

The  Threaded  Proqraiiiiii ng  Technique 

The  HISS  operating  system  software  is  implemotiteil  using  a threaded 
progranming  technique  (Bell,  1973;  Uewer,  1975).  A threaded  program  con- 
sists of  a string  of  indices  indirectly  pointing  to  subprograms  which,  as 
illustrated  by  Figure  3,  may  be  either  machine  code  service  routines  or 
other  threaded  programs.  A threaded  program  itself  does  not  contain  atiy 


I executable  code.  It  just  specifies  the  order  in  which  subthreaded  pro- 

I 

grams  and  service  routines  are  to  be  executed.  Ultimately,  all  coiiputa- 
tion  takes  place  in  machine  code  service  routines  which  may  be  either 
core  resident  or  mixed  with  threaded  programs. 

The  essential  feature  of  this  threaded  programming  technique  is  its 
very  extensive  use  of  subprogram  structures.  The  structuring  of  programs 
using  modular  subprograms  is  generally  agreed  to  be  desirable  (Wright, 1976), 
and  most  programming  languages  provide  some  means  of  accomplishing  it.  For 
example,  the  FORTRAN  language  includes  both  a CALL  statement  for  explicitly 
transferring  control  to  a subprogram  and  a function  expression  for  implicitly 
transferring  control  during  arithmetic  calculations.  This  threaded  pro- 

J 

gramming  technique  takes  the  subprogram  idea  to  its  logical  conclusion, 

making  all  program  statements,  except  those  in  machine  code  service  rou-  j 

tines,  into  implicit  subprogram  calls.  t 

It  is  not  practical  to  use  this  extreme  subprogram  structuring  with  I 

I 

any  of  the  common  programming  languages.  First,  transferring  control  to  < 

j 

a subprogram  is  usually  much  too  slow.  For  example,  in  the  FORTRAN  sys-  | 

tern  provided  with  the  HP  2100,  subprogram  calls  require  hundreds  of  micro-  | 

i 

seconds.  It  is  assumed  in  the  operating  system  and  FORTRAN  conpiler  de- 
signs that  subprogram  calls  are  relatively  rare  in  comparison  with  arith- 
metic operations  and,  therefore,  are  of  little  importance.  Second,  the 

syntax  of  common  languages  permit,  but  do  not  encourage,  the  use  of  sub-  | 

I 

program  structures.  In  the  FORTRAN  language,  each  subprogram  must  be  ! 

J 
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explicitly  defined  by  the  programmer,  is  listed  by  the  compiler  on  a 
separate  page,  and  can  be  called  only  through  limited  kinds  of  syntax. 
Again,  the  language  design  assumes  that  subprogram  calls  are  relatively 
rare  and,  therefore,  that  the  readability  of  subprogram  structures  is 
unimportant.  Subprogram  structures  in  BASIC  are  even  less  efficient  and 
readable. 

FORTH  (Moore,  1974;  Rather  and  Moore,  1976)  and  a similar  laboratory 
computer  operating  system,  CONVERS  (Til den  and  Denton,  1978),  both  make 
use  of  the  threaded  programming  technique.  In  FORTH,  a threaded  program 
is  a string  of  absolute  addresses;  while  in  CONVERS  it  is  a string  of  sub- 
routine call  instructions.  Both  of  these  structures  are  less  efficient  in 
memory  space  than  the  indices  used  in  HISS.  FORTH  has  a very  small  fixed 
kernel  consisting  of  little  more  than  the  threaded  program  interpreter  and 
a couple  of  I/O  drivers.  Everything  else  is  compiled  from  FORTH  source 
code  when  the  system  is  loaded.  CONVERS  includes  a large  number  of  fixed 
machine  code  service  routines  along  with  the  interpreter  and  I/O  drivers 
and  is  compiled  by  a standard  assembler.  HISS  includes  even  more  fixed 
machine  code  service  routines  to  provide  an  interface  with  a more  sophis- 
ticated multiprogramming  monitor.  CONVERS  is  the  simplest  to  implement 
and  is  the  fastest  in  execution  on  the  microcomputers  for  which  it  was  de- 
signed. FORTH,  however,  is  at  least  as  fast  for  most  minicomputers  and 
is  less  machine  dependent.  HISS  requires  a niicroprogrammable  machine  for 
efficient  implementation  and  so,  at  the  lower  levels,  is  very  machine  de- 
pendent. The  high  level  threaded  program  syntax,  however,  is  machine  in- 
dependent as  are  both  FORTH  and  CONVERS. 
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An  interpreter  implemented  in  microcode  for  the  HP  2100  executes 
threaded  programs  by  transferring  control  from  service  routine  to  ser- 
vice routine  in  the  sequence  specified  by  the  threaded  program.  The  in- 
terpreter is  similar  to  the  one  described  by  Bell  (Bell,  1973)  and  works 
in  the  following  way: 

Step  1.  Increment  PC  on  top  of  control  stack. 

Step  2.  Fetch  S from  PCth  address  of  memory. 

Step  3(a).  If  S denotes  a service  routine,  execute  it. 

Step  3(b).  If  not,  push  the  address  of  S to  control  stack. 

Step  4.  Ro  to  Step  1. 

A control  stack  provides  a place  to  save  nested  threaded  program 
return  addresses.  During  each  cycle  of  the  interpreter,  the  address  of 
the  current  threaded  program  instruction  is  present  on  top  of  the  control 
stack.  All  that  is  required  to  begin  interpretation  of  a threaded  pro- 
gram is  to  push  its  address  onto  the  control  stack.  The  return  address 
to  the  calling  threaded  program  is  automatically  saved  on  the  control 
stack  during  subprogram  execution.  Upon  completion  of  a threaded  pro- 
gram, a special  service  routine,  NEXT,  which  is  also  implemented  in  micro- 
code, is  executed  to  delete  the  address  on  top  of  the  control  stack  re- 
turning control  to  the  calling  threaded  program. 

This  threaded  program  interpreter  is  quite  simple  and  fast,  re- 
quiring only  an  average  of  8 microseconds  per  interpreter  cycle.  This  is 
nearly  as  fast  as  the  most  limited  assembly  language  subroutine  call 
and  is  much  faster  than  the  hundreds  of  microseconds  required  for  a typical 
FORTRAN  subroutine  call.  The  interpreter  and  associated  service  routines 
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use  241y  of  the  400^  instruction  words  available  in  the  veritable  con- 
trol store  module.  The  rest  of  this  space  is  available  for  other  uses 
including  user  defined  instructions.  A more  complete  discussion  of  this 
threaded  program  implementation  has  been  described  previously  (Phillips, 
et  al,  1978). 

The  high  speed  of  subprogram  transfers  provided  by  ttie  threaded 
program  interpreter  would  be  lost  without  corresponding  efficiency  in 
passing  parameters  to  and  returning  results  from  subprograms.  The  most 
efficient  means  of  communication  between  subprograms,  through  a data 
stack,  is  used  in  the  HISS  system.  This  data  stack,  although  implemented 
in  a fashion  similar  to  the  control  stack,  is  distinct  from  and  indepen- 
dent of  it.  Any  kind  of  data  may  be  stored  on  the  data  stack,  but  the 
control  stack  is  limited  to  subprogram  return  addresses  and  a few  related 
program  flow  items. 

Most  of  the  stack  oriented  com[iiiters  currently  in  use,  for  oxaiDiile, 
the  HP  3000,  use  a single  stack  for  both  data  and  subprogram  control  in- 
formation (Bulman,  1977).  Each  subprogram  call  and  return  requires  a com- 
plex series  of  operations  to  allocate  stack  memory  and  coniiiuni cate  para- 
meters or  results.  This  single  stack  architecture  is  appropriate  for  lan- 
guages in  which  subprogram  calls  are  relatively  rare,  but  it  cannot  be 
used  for  a threaded  program  system. 

Hierarchical ly  Structured  Software 

The  threaded  programming  technique,  when  combined  with  a suitable 
compiler,  allows  the  development  of  highly  structured  hierarchical  pro- 
grams which,  in  addition  to  being  smaller  in  size  than  cquivali'nt 
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conventionally  structured  programs,  are  also  easier  to  write  and  under- 
stand. Each  threaded  program  is  defined  in  terms  of  more  basic  or  gen- 
eral purpose  instructions  which  are,  in  turn,  programs  defined  from 
even  more  basic  instructions.  At  the  bottom  of  this  hierarchical  struc- 
ture are  microcode  and  assembly  language  service  routines  which  only 
rarely  need  to  be  changed.  Above  them  are  a series  of  levels  of  threaded 
program  building  blocks  defining  all  of  the  operations  needed  for  a par- 
ticular kind  of  application.  At  the  highest  level  are  specific  appli- 
cations programs.  The  language  available  for  implementing  a threaded 
program  becomes  more  specific  as  higher  levels  are  added  to  the  hierarchi- 
cal structure.  It  is  also  the  liigher  levels  which  most  often  have  to 
be  modified  in  a research  environment.  This  hierarchical  structure  se- 
parates tlie  implementation  details  of  a program  from  the  overall  logic 
making  the  program  easier  to  understand  and  modify. 

Some  example  threaded  program  procedures  are  given  in  Figure  4. 

These  procedures  are  part  of  the  intermediate  level  coding  for  a chroma- 
tography simulation  language  or  system  (Phillips  and  Burke,  1978).  They 
are  written  in  terms  of  instructions  implemented  as  lower  level  threaded 
programs  and  service  routines  such  as  NITRATE  and  R.EXP.  These  lower 
level  instructions  are  much  more  specific  than  the  machine's  general  pur- 
pose assembly  language  v;ould  be.  Consequently,  the  exanple  threaded  pro- 
grams are  much  shorter  and  easier  to  understand  than  they  would  he  if  im- 
plemented in  any  general  language.  The  first  two  procedures  in  Figure  4, 
HITSURF  and  STUCK,  are,  in  turn,  used  as  instructions  in  the  third  procedure, 
ADSORB.  By  the  addition  of  these  two  threaded  programs  procedures,  the 
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language  becomes  even  more  specific  and  following  threaded  programs  can 
be  written  on  an  even  higher  level. 

The  lowest  level  service  routines,  such  as  K.tXP,  an  exponential 
random  number  generator,  are  unlikely  to  ever  need  any  changes.  The  code 
for  these  routines  is  compiled  and  stored  separately  to  keep  it  from 
cluttering  the  higher  level  threaded  programs  with  excessive  detail. 

Users  working  at  this  intermediate  level  in  tie  simulation  language  hier- 
archy would  be  interested  only  in  what  an  instruction  does  and  not  how 
it  does  it.  These  intermediate  level  threaded  programs  would,  in  turn, 
be  uninteresting  implementation  details  for  a user  manipulating  models 
of  chromatographic  processes. 

Most  of  the  logic  of  the  operating  system  is  implemented  with 
threaded  code  in  a fashion  similar  to  the  chromatography  simulation 
example  illustrated  by  Figure  5.  Included  among  these  routines  are  execu- 
tive call  interpreters,  a file  manager,  and  interactive  user  interface. 
Threaded  code  is  resident  in  a virtual  memory  with  currently  active 
pages  in  core  and  inactive  pages  kept  in  a support  file  on  disc.  This 
allows  for  future  expansion  of  system  functions  without  increasing  the 
amount  of  core  memory  occupied  since  additional  threaded  programs  remain 
on  disc  until  actually  used  and  then  automatically  displace  other  unused 
programs  from  core. 

The  minimum  amount  of  virtual  memory  support  core  for  efficient 
system  operation  is  65  pages  of  32  words  each.  Core  resident  assembly 
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language  routines  and  system  communication  tables  require  about  7,000 
words  of  memory.  Thus,  the  total  HISS  system  requires  about  9,000  words 
of  core  memory  leaving  23,000  words  for  user  programs  or  data. 

The  operating  system  software  is  organized  in  a hierarchical  struc- 
ture as  shown  in  Figure  5.  Control  flows  from  higher  to  lower  levels  in 
this  structure;  that  is,  routines  at  a higher  level  can  direct  the  activity 
of  routines  at  lower  levels,  but  lower  level  routines  can  only  return  in- 
formation or  make  requests  of  higher  level  routines.  The  user  interface 
to  the  conputer  system  is  through  the  system  supervisor  at  the  highest 
level.  Peripheral  computer  software  is  at  a lower  level  than  the  com- 
munication network  manager  and,  therefore,  peripheral  computer  programs 
can  make  requests  but  cannot  control  the  central  conputer  system. 

All  of  the  system  software,  except  for  a small  netvork  communica- 
tions driver,  resides  in  the  central  conputer.  Thus,  the  peripheral 
computers  are  dedicated  to  applications  programs,  while  the  central  com- 
puter provides  operation  system  services  sharing  its  resources  anong 
the  users.  An  applications  program  in  a peripheral  conputer  needing  some 
system  service  makes  a request  through  its  coninuni cations  network  driver. 
The  central  computer  software  then  answers  this  request  by  taking  control 
of  the  peripheral  computer,  interpreting  its  request,  and  either  perform- 
ing the  requested  service  itself  or,  in  the  case  of  data  transfers,  tell- 
ing the  peripheral  computer  how  to  perform  the  required  operations.  Only 
the  central  computer  software  is  capable  of  interpreting  system  requests, 
whether  from  a user  at  a terminal,  a program  in  the  central  conputer,  or 
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an  applications  program  in  a peripheral  computer.  In  all  cases,  the 
central  computer  plays  the  role  of  master  and  the  peripheral  computers 
act  as  slaves  under  its  control  so  long  as  the  communications  netv/ork 
driver  is  present  in  their  memory.  The  peripheral  slave  computers  can 
make  requests  and  the  central  master  computer  will  carry  them  out  if  it 
understands  them  and  accepts  them  as  appropriate. 

Conclusion 

The  hierarchical  organization  used  extensively  in  the  design  of 
this  system  has  proved  to  be  a very  useful  approach  for  both  hardware 
and  software  coiiponents  of  laboratory  coiiputer  systems.  It  is  essential 
to  use  definite  structures  in  the  design  of  anything  as  conplex  as  an 
operating  system.  The  hierarchical  structure  is  one  of  the  most  general 
possible  allowing  it  to  be  used  in  ma?iy  different  places  in  the  system. 
It  is  also  an  ideal  way  of  dividing  conplex  problems  into  smaller  and 
simpler  pieces  with  the  usual  result  being  iiwre  general  solutions  and 
software  is  easier  to  understand,  naintain,  and  extend. 

Most  of  the  goals  originally  set  for  the  system  have  been  met. 

The  peripheral  conputers  provide  very  good  real-tiiiK?  data  acquisition. 
The  resulting  data  can  be  transmitted  at  high  speed  to  the  central  com- 
puter and  stored  on  disc.  Interactive  control  of  experiments  is  pro- 
vided by  user  programs  in  the  peripheral  conputers.  The  system  helps 
only  indirectly  in  this  by  rapidly  iipving  data  out,  but  at  least  it  does 
not  limit  the  user  program  as  many  systems  do,  since  it  is  located  in 
another  processor.  Sophisticated  data  massaging  during  experiments  is 
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available  in  the  central  computer.  Fast  computation  is  available  as 
demonstrated  by  a chromatography  simulation  program  (PItillips  and  burke, 
1978).  The  system  software  is  extremely  modular  making  it  much  more 
maintainable  than  iicst  operating  systems.  This  modularity,  plus  the  hier- 
archical structure  provided  by  the  threaded  programming  technique,  should 
make  future  expandability  of  the  system  easier  and  provide  hardware  inde- 
pendence for  much  of  the  system  programming.  The  flexibility  necessary 
in  a research  environment  is  provided  by  giving  complete  control  of  the 
peripheral  computers  to  the  user  programs  resident  in  them  during  perfor- 
mance of  experiments.  This  is  the  most  iiiportant  place  in  the  system  to 
have  extremely  good  flexibility.  Other  user  programs  are  more  structured 
by  the  system  supplied  services. 

The  HISS  threaded  programming  technique,  one  of  tl-e  most  ii«;e1ul  re- 
sults of  this  project,  could  be  improved  in  two  ways.  First,  tlie  present 
threaded  code  conviler  is  based  on  a general  purpose  macro  interpreter. 
This  approach  allowed  extensive  experimentation  in  the  syntax  of  tlireaoed 
programs  in  the  early  stages  of  this  project  and  resulted  in  a nwre  read- 
able and  easier  to  use  language.  Replacing  this  conpiler  could  improve 
the  system's  interactive  capabilities.  Second,  the  threaded  program 
technique  should  be  nvade  available  in  peripheral  conputers.  This  would 
require  that  mi croprograimiing  capabilities  be  added  to  then. 

As  a prototype  operating  system  for  laboratory  conputers,  this  de- 
sign includes  several  features  which  are  likely  to  become  more  important 
as  newer  and  less  expensive  hardv;are  becomes  available.  The  continuing 
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decrease  in  prices  of  processors  and  iiieiiiory  is  changing  the  economics  of 
laboratory  computing  in  favor  of  distributed  systems.  And,  as  the  hard- 
ware designs  change,  so  must  the  software  systems  change. 

Real-time  multiprocessing  systems  in  which  a single  processor  is 
shared  anong  several  concurrent  tasks  are  becoming  much  less  attractive 
for  laboratory  computing.  By  assigning  separate,  less  powerful,  processors 
to  each  task,  much  can  be  saved  in  software  complexity  with  little  cost 
in  hardware.  The  HISS  system  uses  fairly  expensive  minicomputers  to  do 
this  because  they  were  what  was  available  during  its  design,  but  the 
principle  of  hierarchical  processors  applies  just  as  well  to  the  newer 
and  less  expensive  microprocessors.  Having  a peripheral  computer  whose 
only  responsibility  is  to  service  a particular  instrument  greatly  re- 
duces software  cost  and  comolexity  while  improving  service  to  that  instru- 
ment. Expensive  peripheral  equipment  can  be  shared  by  attaching  it  to 
one  central  computer. 

The  HISS  system  provides  capabilities  useful  in  a chemical  research 
laboratory  wliich  were  not  previously  available  and  is  an  advance  in  the 
design  of  laboratory  computer  systems.  Its  hierarchical  design  is  a 
very  good  approach  to  building  such  an  operating  system  and  makes  it  much 
nore  maintainable  and  extendable  by  its  users.  Systems  like  this  one 
are  likely  to  become  nwre  coiiron  and  more  important  as  tlie  need  for  and 
uses  of  laboratory  computers  increases.  This  approach  to  software  de- 
sign can  be  expected  to  influence  future  computer  hardware  resulting  in 
laboratory  comf)Uter  systems  better  able  to  assist  in  chemical  research. 

Uetailed  listings  and  other  system  documentation  will  be  made 
available  to  interested  readers. 
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Figure  Captions 


1.  mss  Hardware  Organization 

2.  Simplified  Schematic  of  the  Communication  Network  Multiplexer 

3.  Structure  of  a Threaded  Program 

4.  example  Threaded  Programs 

5.  HISS  Software  Organization 
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